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Abstract 


DNS messages between clients and servers may be received over either 
UDP or TCP. UDP transport involves keeping less state on a busy 
server, but can cause truncation and retries over TCP. Additionally, 
UDP can be exploited for reflection attacks. Using TCP would reduce 
retransmits and amplification. However, clients commonly use TCP 
only for retries and servers typically use idle timeouts on the order 
of seconds. 


This document defines an EDNSO option ("edns-tcp-keepalive") that 

allows DNS servers to signal a variable idle timeout. This 

signalling encourages the use of long-lived TCP connections by 

allowing the state associated with TCP transport to be managed 

effectively with minimal impact on the DNS transaction time. 
Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7828. 
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document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
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include Simplified BSD License text as described in Section 4.e of 
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Les 


Introduction 


DNS messages between clients and servers may be received over either 
UDP or TCP [RFC1035]. Historically, DNS clients used APIs that only 
facilitated sending and receiving a single query over either UDP or 
TCP. New APIs and deployment of DNSSEC validating resolvers on hosts 
that in the past were using stub resolving only is increasing the DNS 
client base that prefer using long-lived TCP connections. Long-lived 
TCP connections can result in lower request latency than the case 
where UDP transport is used and truncated responses are received. 
This is because clients that retry over TCP following a truncated UDP 
response typically only use the TCP session for a single (request, 
response) pair, continuing with UDP transport for subsequent queries. 


The use of TCP transport requires state to be retained on DNS 
servers. If a server is to perform adequately with a significant 
query load received over TCP, it must manage its available resources 
to ensure that all established TCP sessions are well-used, and idle 
connections are closed after an appropriate amount of time. 


UDP transport is stateless, and hence presents a much lower resource 
burden on a busy DNS server than TCP. An exchange of DNS messages 
over UDP can also be completed in a single round trip between 
communicating hosts, resulting in optimally short transaction times. 
UDP transport is not without its risks, however. 


A single-datagram exchange over UDP between two hosts can be 
exploited to enable a reflection attack on a third party. Response 
Rate Limiting [RRL] is designed to help mitigate such attacks against 
authoritative-only servers. One feature of RRL is to let some amount 
of responses "slip" through the rate limiter. These are returned 
with the TC (truncation) bit set, which causes legitimate clients to 
resend the same query using TCP transport. 


[RFC1035] specified a maximum DNS message size over UDP transport of 
512 bytes. Deployment of DNSSEC [RFC4033] and other protocols 
subsequently increased the observed frequency at which responses 
exceed this limit. EDNSO [RFC6891] allows DNS messages larger than 
512 bytes to be exchanged over UDP, with a corresponding increased 
incidence of fragmentation. Fragmentation is known to be problematic 
in general, and has also been implicated in increasing the risk of 
cache poisoning attacks [fragmentation-considered-poisonous]. 


TCP transport is less susceptible to the risks of fragmentation and 
reflection attacks. However, TCP transport for DNS as currently 
deployed has expensive setup overhead, compared to using UDP (when no 
retry is required). 
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The overhead of the three-way TCP handshake for a single DNS 
transaction is substantial, increasing the transaction time for a 
single (request, response) pair of DNS messages from 1x RTT to 2x 
RTT. There is no such overhead for a session that is already 
established; therefore, the overhead of the initial TCP handshake is 
minimised when the resulting session is used to exchange multiple DNS 
message pairs over a single session. The extra RIT time for session 
setup can be represented as the equation (1 + N)/N, where N 
represents the number of DNS message pairs that utilize the session 
and the result approaches unity as N increases. 


With increased deployment of DNSSEC and new RR types containing 
application-specific cryptographic material, there is an increase in 
the prevalence of truncated responses received over UDP with retries 
over TCP. The overhead for a DNS transaction over UDP truncated due 
to RRL is 3x RIT higher than the overhead imposed on the same 
transaction initiated over TCP. 


This document proposes a signalling mechanism between DNS clients and 
servers that encourages the use of long-lived TCP connections by 
allowing the state associated with TCP transport to be managed 
effectively with minimal impact on the DNS transaction time. 


This mechanism will be of benefit for both stub-resolver and 
resolver-authoritative TCP connections. In the latter case, the 
persistent nature of the TCP connection can provide improved defence 
against attacks including DDoS. 


The reduced overhead of this extension adds up significantly when 
combined with other EDNSO extensions, such as [CHAIN-QUERY] and 
[DNS-over-TLS]. For example, the combination of these EDNSO 
extensions make it possible for hosts on high-latency mobile networks 
to natively and efficiently perform DNSSEC validation and encrypt 
queries. 


2. Requirements Notation 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 
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The edns-tcp-keepalive Option 


This document specifies a new EDNSO [RFC6891] option, edns-tcp- 
keepalive, which can be used by DNS clients and servers to signal a 
willingness to keep an idle TCP session open to conduct future DNS 
transactions, with the idle timeout being specified by the server. 
This specification does not distinguish between different types of 
DNS client and server in the use of this option. 


[RFC7766] defines an ’idle DNS-over-TCP session’ from both the client 
and server perspective. The idle timeout described here begins when 
the idle condition is met per that definition and should be reset 
when that condition is lifted, i.e., when a client sends a message or 
when a server receives a message on an idle connection. 


1. Option Format 


The edns-tcp-keepalive option is encoded as follows: 


1 2 3 
0123456789012345678°9012345678901 
4+------------------------------- 4+------------------------------- + 
! OPTION-CODE ! OPTION-LENGTH ! 
4+------------------------------- 4+------------------------------- + 
TIMEOUT ! 
4+------------------------------- + 
where: 
OPTION-CODE: the EDNSO option code assigned to edns-tcp-keepalive, 
11 
OPTION-LENGTH: the value 0 if the TIMEOUT is omitted, the value 2 
if it is present; 
TIMEOUT: an idle timeout value for the TCP connection, specified in 


units of 100 milliseconds, encoded in network byte order. 


.2. Use by DNS Clients 


-2.1. Sending Queries 


DNS clients MUST NOT include the edns-tcp-keepalive option in queries 
sent using UDP transport. 


DNS clients MAY include the edns-tcp-keepalive option in the first 
query sent to a server using TCP transport to signal their desire to 
keep the connection open when idle. 
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DNS clients MAY include the edns-tcp-keepalive option in subsequent 
queries sent to a server using TCP transport to signal their 
continued desire to keep the connection open when idle. 


Clients MUST specify an OPTION-LENGTH of 0 and omit the TIMEOUT 
value. 


3.2.2. Receiving Responses 


A DNS client that receives a response using UDP transport that 
includes the edns-tcp-keepalive option MUST ignore the option. 


A DNS client that receives a response using TCP transport that 
includes the edns-tcp-keepalive option MAY keep the existing TCP 
session open when it is idle. It SHOULD honour the timeout received 
in that response (overriding any previous timeout) and initiate close 
of the connection before the timeout expires. 


A DNS client that receives a response that includes the edns-tcp- 
keepalive option with a TIMEOUT value of 0 SHOULD send no more 
queries on that connection and initiate closing the connection as 
soon as it has received all outstanding responses. 


A DNS client that sent a query containing the edns-keepalive-option 
but receives a response that does not contain the edns-keepalive- 
option SHOULD assume the server does not support keepalive and behave 


following the guidance in [RFC7766]. This holds true even if a 
previous edns-keepalive-option exchange occurred on the existing TCP 
connection. 


3.3. Use by DNS Servers 
3.3.1. Receiving Queries 


A DNS server that receives a query using UDP transport that includes 
the edns-tcp-keepalive option MUST ignore the option. 


A DNS server that receives a query using TCP transport that includes 
the edns-tcp-keepalive option MAY modify the local idle timeout 
associated with that TCP session if resources permit. 


3.3.2. Sending Responses 


A DNS server that receives a query sent using TCP transport that 
includes an OPT RR (with or without the edns-tcp-keepalive option) 
MAY include the edns-tcp-keepalive option in the response to signal 
the expected idle timeout on a connection. Servers MUST specify the 
TIMEOUT value that is currently associated with the TCP session. It 
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is reasonable for this value to change according to local resource 
constraints. The DNS server SHOULD send an edns-tcp-keepalive option 
with a timeout of 0 if it deems its local resources are too low to 
service more TCP keepalive sessions or if it wants clients to close 
currently open connections. 


3.4. TCP Session Management 


Both DNS clients and servers are subject to resource constraints that 
will limit the extent to which TCP sessions can persist. Effective 
limits for the number of active sessions that can be maintained on 
individual clients and servers should be established, either as 
configuration options or by interrogation of process limits imposed 
by the operating system. Servers that implement edns-tcp-keepalive 
should also engage in TCP connection management by recycling existing 
connections when appropriate, closing connections gracefully, and 
managing request queues to enable fair use. 


In the event that there is greater demand for TCP sessions than can 
be accommodated, servers may reduce the TIMEOUT value signalled in 
successive DNS messages to minimise idle time on existing sessions. 
This also allows, for example, clients with other candidate servers 
to query to establish new TCP sessions with different servers in 
expectation that an existing session is likely to be closed or to 
fall back to UDP. 


Based on TCP session resources, servers may signal a TIMEOUT value of 
0 to request clients to close connections as soon as possible. This 
is useful when server resources become very low or a denial-of- 
service attack is detected and further maximises the shifting of 
TIME_WAIT state to well-behaved clients. 


However, it should be noted that RFC 6891 states: 


Lack of presence of an OPT record in a request MUST be taken as an 
indication that the requestor does not implement any part of this 
specification and that the responder MUST NOT include an OPT 
record in its response. 


Since servers must be faithful to this specification even ona 
persistent TCP connection, it means that (following the initial 
exchange of timeouts) a server may not be presented with the 
opportunity to signal a change in the idle timeout associated with a 
connection if the client does not send any further requests 
containing EDNSO OPT RRs. This limitation makes persistent 
connection handling via an initial idle timeout signal more 
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attractive than a mechanism that establishes default persistence and 
then uses a connection close signal (in a similar manner to HTTP 1.1 
[RFC7230]). 


If a client includes the edns-tcp-keepalive option in the first 
query, it SHOULD include an EDNSO OPT RR periodically in any further 
messages it sends during the TCP session. This will increase the 
chance of the client being notified should the server modify the 
timeout associated with a session. The algorithm for choosing when 
to do this is out of scope of this document and is left up to the 
implementor and/or operator. 


DNS clients and servers MAY close a TCP session at any time in order 
to manage local resource constraints. The algorithm by which clients 
and servers rank active TCP sessions in order to determine which to 
close is not specified in this document. 


3.5. Non-clean Paths 


Many paths between DNS clients and servers suffer from poor hygiene, 
limiting the free flow of DNS messages that include particular EDNSO 
options or messages that exceed a particular size. A fallback 
strategy similar to that described in [RFC6891], Section 6.2.2 SHOULD 
be employed to avoid persistent interference due to non-clean paths. 


3.6. Anycast Considerations 


DNS servers of various types are commonly deployed using anycast 
[RFC4786]. 


Changes in network topology between clients and anycast servers may 
cause disruption to TCP sessions making use of edns-tcp-keepalive 
more often than with TCP sessions that omit it, since the TCP 
sessions are expected to be longer lived. It might be possible for 
anycast servers to avoid disruption due to topology changes by making 
use of TCP multipath [RFC6824] to anchor the server side of the TCP 
connection to an unambiguously unicast address. 


4. Intermediary Considerations 


It is RECOMMENDED that DNS intermediaries that terminate TCP 
connections implement edns-tcp-keepalive. An intermediary that does 
not implement edns-tcp-keepalive but sits between a client and server 
that both support edns-tcp-keepalive might close idle connections 
unnecessarily. 
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Security Considerations 


April 2016 


The edns-tcp-keepalive option can potentially be abused to request 


large numbers of long-lived sessions in a quick burst. 


When a DNS 


server detects abusive behaviour, it SHOULD immediately close the TCP 


connection and free the resources used. 


Servers could choose to monitor client behaviour with respect to the 
edns-tcp-keepalive option to build up profiles of clients that do not 


honour the specified timeout. 


Readers are advised to familiarise themselves with the security 


considerations outlined in [RFC7766] 


IANA Considerations 


IANA has assigned an EDNSO option code for the edns-tcp-keepalive 
option from the "DNS EDNSO Option Codes (OPT)" registry as follows: 
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